我为什么劝你放弃个人代码所有权？

来源：DEV

作者：Lorenzo Pasqualis

智能观 编译

编码是一种艺术形式，而艺术家们非常重视他们的作品。这种发自内心的依恋让程序员们充满激情。这可能是件好事，但也可能导致问题。

除非整个开发团队只有一两个开发人员，否则在意个人的代码所有权是一种病态的行为。我不推荐，也不鼓励。原因如下：

1. 对代码的情感依恋伤害了集体智慧

有的程序员会认为代码的版权应该归自己。这种情绪导致代码成了他人不可侵犯的，而这种教条主义思维会发展成权属之争。当涉及这种情绪时，要进行代码审查是相对困难的。除非代码的所有者同意别人更改，否则无法进行改进。

我观察了一些团队的软件开发过程，认为团队理念应该被延伸到开发的所有权、目标、过程，衡量成功的方式以及如何庆祝等所有方面。如同一个球队赢了球，不能说是某个球员自己的胜利，而是团队的胜利。每个成员都是一个有机体，是完成工作的重要组成部分。赢得比赛的是球队，而不是某个球员。同样地，开发人员不应该感到自己拥有代码。相反，他们应该觉得自己是构建代码的必要组成部分，是为组织工作而不是自己打游戏。

作为工程文化的组成部分，正确地培养对代码的感觉需要公司顶层的支持，最好是在一项新工程开始时就着手准备。如果鼓励恰当，这种文化就会在团队中形成，成为现实。

2.个人代码所有类似流水线上的单点故障

开发者本身会有生病、辞职、升职、转行、出国、死亡等任何你能想到的不测。把一个公司知识产权的重要部分与某个人联系在一起，是通往灾难的单行道。个人代码所有权会将公司的健康状况与代码所有者个人的健康状况，或与所有者/公司之间关系的健康状况联系起来。

如果一个开发人员拥有代码权，那么开发人员就成了一个单点故障。如果他或她发生了什么事，公司就要承担后果。代码越复杂，公司需要承受的损害就越大，回到正轨的时间也就越长。

3.团队比个体之和更强大

一个有才华的开发者可以创造出惊人的价值，但是一个由N个开发者组成的团队创造的价值会超过N个开发者开发价值之和。头脑风暴、协作和反馈可以提高开发人员的质量和产出，不管他或她多么有才华。当一个人拥有代码时，头脑风暴和协作就要让位于所有权，而结果会影响产品的质量。

也许你会认为几个开发人员独自工作比一个小团队一起工作要好得多。一个开发人员单独工作可能会更快地产生一些实际的结果，这对解决一个问题来说是很好的，但其整体结果的质量和寿命是有限的，这对企业来说并不理想。

4. 代码是一种产品，属于团队拥有

没有人会这么想问题，到底房子属于建造它的木匠，还是属于购买它的房主。这是因为房子是一个物理实体，它具有我们所认为的买方拥有的实体品质。当你在商店里买了食物，那就是你的食物。如果你买了一辆车，那就是你的车。再明显不过!

当一个产品是概念性的，事情就不那么明显了。例如，小说的作者拥有故事版权，而买书的人只拥有纸质书。软件更接近一个概念而不是一个物理对象，而开发人员，特别是小公司的开发人员，觉得自己拥有它。他们有这种感觉，因为他们是唯一了解细节的人。这是一种自然倾向，但同时也是一种谬论。

软件由公司所有，而不是由开发人员拥有。从法律上讲，这是软件开发人员和他们的雇主之间的雇佣合同中所规定的事实，但人们每天的感觉可能都不一样。虽然技术团队应该对工作有责任感，但开发人员不应该产生个人所有制的感觉。

5. 创新需要一个组织

如果一个开发人员单独拥有代码权，TA就要完成所有的创新。听起来不是很荒谬吗?作为一个独自工作的工程师，确实可以做到快速创新，但很快就达到能力的极限了。另一方面，一个团队可以通过集体智慧，头脑风暴，从不同角度看问题，将一个人无法拥有的丰富经验搬上台面，进行创新。

如果团队随时做出改变，引进拥有不同经验的新成员，其创新的质量就会增长，新概念的火花也会被重新点燃。

6.个人代码所有权会导致停滞

缺乏创新会导致工程停滞不前。长期处于孤立状态下的程序员往往会被他们已习惯的观念所影响。

他们会不同程度地抗拒工作上的任何改变，因为固化的观念已经给他们带来了复杂的意义。如果与他们的观念不一致，那些来自外部的想法最终就会被过滤掉。如果是在创业初期，这样做可能是件好事。然而，时间一久，这种开发软件的方式就很难扩展了，继而将不再有创新。

7.个人代码所有权会阻碍个人进步

那些整天独自在同一个代码库工作的开发人员变成了笼子里的鸽子。这意味着他们在任何不是他们专长领域的地方都变得迟钝，裹足不前。

我曾经看到过来自大企业的开发人员，他们在同一个应用程序的同一个对话框上工作了多年(微软的一些部门曾经因此而臭名昭著)。这种专业化是极端个人代码所有权所导致的结果，造成了个人成长的损失。

8.个人代码所有权阻碍了职业发展

如果一个开发人员把自己和他们的代码捆绑在一起，那么他们不仅是上面所提到的单点故障，还很难晋升到更高的职位，因为没有简单的方法来替代他们所负责的工作。

我之前在一篇题为《Work yourself out of your job》的文章中谈到了这一点：“要得到晋升，你必须放弃你宝贵的经验，把自己从目前的工作中摆脱出来，这样你就可以开始一个更高级别头衔的新工作。”个人代码所有权限制了这种可能性。开发人员若想提升，要做的第一件事就是确保他们不是某部分代码库的所有者。

个人代码所有权通常是自己造成的，因此也很容易被自己撤销。为了做到这一点，开发人员需要友善地鼓励其他工程师接触自己编写的代码，并协助他们熟悉它。一开始，让所有权消失会有风险。这会让你觉得你把自己从工作中赶了出来，但这是正确的做法，去做不同的更好的事情会更有益。

9.个人代码所有权是工程师们的监狱

 “拥有”部分代码，感到不可缺少，这可能会给人一种职业安全感的错误印象。然而，工作安全看起来更像把自己关进监狱，而不是待在一个舒服的地方。不学习新技能，没有职业发展，一个软件工程师就像被关在自制的监狱里，而且这个监狱空间还会变得越来越小。

几年前，我读了一篇优秀的文章，标题为《Give Away Your Legos, and Other Commandments for Scaling Startups》。它谈到了创业公司的可扩展性，同样的概念也适用于个人的可扩展性和职业发展。如果一个开发人员整日把自己的“乐高积木”放在身边，小心翼翼地保护着，就等同于用乐高砖给自己建造了一座乐高监狱。

放弃你的乐高积木吧，重塑自我，继续前进。

10.开发人员坚持他们的代码所有权，易与领导冲突

在技术世界里，市场总是在不断变化，产品亦然。有时产品变更必须是激进的，开发人员需要适应和支持领导要求的变更。当个人代码所有权的感觉过于强烈时，开发人员往往会与领导产生分歧并抵制变更。这种行为会导致冲突，要么减缓进度，要么被解雇。

如果在一些大型机构，整个团队都会因为一个项目取消而被解雇。试想，为什么一个公司会因为一个项目被取消而解雇一个有才华的工程师团队呢?如果工程师能毫无问题地进行新项目，公司会解雇他们吗?现实情况是，有时候，团队是围绕项目形成的。个人过分专注于一个项目，拥有它并小心地保护它，失去了适应新项目的能力，拒绝改变，拒绝放手，得到的不仅是一所监狱，还可能是专业的棺材。

11.个人代码所有权导致不信任

一些认为有必要拥有和捍卫代码权的开发人员正在传播一种不良印象:都给我躲开!我才是唯一能理解或接触这段代码的人。

这种印象可能不会被明确表达出来，但整个工程团队都会有感觉，有意或无意地认为这是不信任的信号。当同一团队的成员明确知道彼此不信任时，团队很容易遭受损失，并失去快速行动的能力。不信任会导致不良摩擦，这会消耗宝贵的能量，但不会产生任何积极的结果。

当开发人员开始放下他们的个人代码所有权意识时，事情就会改变。信任成为工作方式的一部分，团队合作成为驱动力。团队在一个充满信任的环境中运行，会产生更好的结果，并变得更有弹性。

12.拒绝分享对组织的发展没有好处

感觉自己单独拥有代码的开发人员常常觉得他们不需要任何流程来指导他们。Agile方法中如Scrum或其他形式的组织结构对这些开发人员来说似乎是外来的和不必要的。这点和一个拒绝在任何压力、结构或约束下工作的艺术家来说并不一样。

这种软件开发的观点根植于早期的黑客时代，是那时很典型的年轻开发者的生活。单飞、学习、成长，长时间占据一个程序员的生活，他们和流程中其他人没有任何关联。这种工作方式是缺少弹性的。当一个或两个以上的人参与一个项目时，辉煌的黑客时代使用的方法便不再有利于工作。

在开发人员作为团队的一部分进行工作时，流程成为一个重要的工具。它有助于同步工作并确保高效、可预测和有组织地交付结果。黑客和开发软件之间存在着巨大的差异。前者可能很有趣，后者则是工程组织如何规模化。

原文链接：https://dev.to/lpasqualis/12-reasons-to-avoid-individual-code-ownership?nsukey

—完—

想知道AI加教育领域有哪些最新研究成果？请在智能观（zhinengguanym）对话界面回复“论文”；

想要AI领域更多的干货？请在对话界面回复“干货”；

想了解更多专家的“智能观”，请在对话界面回复“观点”，去获取你想要的内容吧。

有人问：你们为什么要做智能观？为什么关注AI+教育？

我想，这不是一个选择。

当AI开始颠覆各行各业时，我们首先想到了教育。未来是我们正在为之努力的地方，教育可以影响当下，改变未来。

我们用心观察和记录教育在这个时代的蜕变；努力把前沿的动态、最新的进展、先进的观点带到你面前，希望与你一起思考和探索。我们相信，长出AI翅膀的教育，会创造出无限可能。